home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-pem-mime-02.txt
< prev
next >
Wrap
Text File
|
1993-04-19
|
25KB
|
823 lines
Network Working Group Steve Crocker
Internet Draft Ned Freed
Marshall Rose
MIME-PEM Interaction
Thu Apr 18 14:00:00 1993
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
2. Abstract
This memo defines a framework for interaction between MIME and
PEM services. MIME [3], an acronym for "Multipurpose Internet
Mail Extensions", defines the format of the contents of
Internet mail messages and provides for multi-part textual and
non-textual message bodies. PEM [4-7], an acronym for
"Privacy Enhanced Mail", provides message encryption and
authentication services for Internet mail messages.
draft MIME-PEM Interaction Apr 93
3. Introduction
An Internet electronic mail message consists of two parts: the
headers and the body. The headers form a collection of
field/value pairs structured according to RFC 822 [1], whilst
the body, if structured, is defined according to MIME. MIME
does not provide encryption or authentication services.
PEM allows encryption and authentication services to be
applied to the contents of electronic mail messages but does
not provide message structuring or type labelling facilities.
This memo defines a framework whereby the services provided by
MIME and PEM are used in a complementary fashion. The
resulting combined service provides encryption and
authentication services for multi-part text and non-text
messages.
MIME-PEM interaction is provided for by defining four new MIME
content types: multipart/pem, application/pem, message/pem-
clear, and application/pem-encrypted. Then the relationship
between MIME and PEM is described in terms of two functions:
message composition and message delivery.
4. Definiton of new Content Types
4.1. Multipart/pem Content Type Definition
(1) MIME type name: multipart
(2) MIME subtype name: pem
(3) Required parameters: boundary, privacy
(4) Optional parameters: none
Expires Oct 18, 1993 [Page 2]
draft MIME-PEM Interaction Apr 93
(5) Encoding considerations: Either 7bit, 8bit, or binary
encoding may be used, depending on the nested part
encodings and transport limitations.
(6) Security Considerations: see [4]
This subtype of multipart always contains two body parts. The
contents of the first body part contains the privacy-enhanced
content and corresponds to the <pemtext> production as defined
in section 9 of [4]. The first part's content type is either
message/pem-clear or application/pem-encrypted.
The second part describes the privacy enhancement which was
applied to the first body part. The second part's content type
is always application/pem.
The syntax and semantics of the boundary parameter is defined
in [3].
The syntax of the privacy parameter, using the ABNF notation
of [1], is:
privacy-value ::= "ENCRYPTED"
/ "MIC-ONLY"
with each value conveying the intent of the PEM Proc-Type:
field as specified in section 4.6.1.1 of [4]. Note that MIC-
CLEAR is not provided directly; it is subsumed by the
combination of MIC-ONLY and the MIME Content-Transfer-Encoding
mechanism that is available to any body part.
4.2. Message/pem-clear Content Type Definition
(1) MIME type name: message
(2) MIME subtype name: pem-clear
(3) Required parameters: none
Expires Oct 18, 1993 [Page 3]
draft MIME-PEM Interaction Apr 93
(4) Optional parameters: none
(5) Encoding considerations: Any transport-compatible
encoding capable of accomodating the range of data
present in a particular message may be used. Use of
quoted-printable is strongly recommended in order to
guard against inadvertent corruption that would otherwise
lead to validation failures.
(6) Security Considerations: see [4]
The canonical form of this content type corresponds to the
<pemtext> after integrity checks have been computed.
This content type occurs only inside of a multipart/pem
content type.
4.3. Application/pem-encrypted Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-encrypted
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: Any transport-compatible
encoding capable of accomodating binary data may be used.
However, base64 is recommended in order to be backwards-
compatible with the original PEM encoding conventions.
(6) Security Considerations: see [4]
The canonical form of this content type corresponds to the
<pemtext> after encryption processing.
This content type occurs only inside of a multipart/pem
content type.
Expires Oct 18, 1993 [Page 4]
draft MIME-PEM Interaction Apr 93
4.4. Application/pem Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [4]
The canonical form of this content type corresponds to the
<pemhdr> production defined in section 9 of [4].
This content type may be used both as a subpart of the
multipart/pem content type and as an independent bodypart to
represent certificates and certificate revocation lists
(CRLs). Certificates and CRLs are not always associated with
any <pemtext>.
5. Message Composition
When a user composes a message, it is the responsibility of
the user agent to construct a valid MIME message. In
particular, Content-Type: and Content-Transfer-Encoding:
headers should be used wherever they are appropriate. This
allows the receiving user agent to unambiguously interpret the
message body and process it accordingly.
Each block of content headers associated with either an RFC822
<message> or with a MIME <body-part> represents a logical
place where privacy enhancement can be requested. A privacy
enhancement request associated with a particular <message> or
<body-part> content is taken to apply to the entire content;
it is not possible to privacy-enhance only a portion of a body
part.
Expires Oct 18, 1993 [Page 5]
draft MIME-PEM Interaction Apr 93
Since the semantics of privacy enhancment requests closely
parallel those of an additional Content- header, the use of an
additional Content- header for this purpose is a reasonable,
but not mandatory, approach. If a Content- header is used for
this purpose, this memo suggests that a new header field,
"Content-Privacy", be used for this purpose. The syntax of
this header field corresponds to the <privacy-value>
production defined above.
NOTE
The Content-Privacy header is defined here for
illustrative purposes only; this RFC does not recommend
any one specific mechanism. The interface between the
message composer and pre-submission processing is
entirely a local matter, and in general any mechanism
with semantics comparable to a Content-Privacy header can
be used. More to the point, the interface between the
message composer and pre-submission processing MUST be
trustworthy, since the message composer relies on pre-
submission processing to either perform the requested
privacy enhancement operation or return an error.
Regardless of the mechanism chosen, great care should be
taken to safeguard against both the release of
information that has not received the requested sort of
privacy enhancement as well as tampering with the
enhancement request itself.
5.1. Pre-Submission Algorithm
Prior to submission, the user agent first composes a MIME-
compliant message and then applies this algorithm:
(1) If the content at this (initially top) level has NOT been
selected for privacy enhancement, the user agent sees if
the content is either multipart or message. If so, it
then recursively applies this algorithm to the
encapsulated body parts; if not, it terminates processing
for this content.
(2) If the content has been selected for privacy enhancement,
the content is transformed from local form to its MIME
Expires Oct 18, 1993 [Page 6]
draft MIME-PEM Interaction Apr 93
binary canonical form. If Content-Transfer-Encoding:
headers are present the content encoding is reversed as a
part of this process, leaving only 7BIT, 8BIT, and BINARY
as possible encodings for all body parts. This is done
so that any artifacts introduced by encoding are removed
and consistent integrity checks will be generated.
(3) Once binary canonical form has been produced the selected
privacy-enhancement is performed. If encryption
processing is performed an entirely new content is
generated which replaces the original content. <pemhdr>
information is also produced by this process.
(4) A new part is then constructed with the privacy-enhanced
material as its content. This part is labelled with a
content type of either message/pem-clear (if the
privacy-enhancement is MIC-ONLY) or application/encrypted
(if the privacy-enhancement is ENCRYPTED). An
appropriate transfer encoding is also applied to the
content and a corresponding Content-Transfer-Encoding:
header is added to the new part. Base64 encoding is
recommended in the case of ENCRYPTED privacy-enhancement
in order to be backwards-compatible with the original PEM
conventions. When MIC-ONLY privacy-enhancement is used a
transfer encoding other than 7bit must be used only if
the content data requires it. However, at a minimum the
use of the quoted-printable encoding is strongly
recommended to insure that the message is not damaged in
transit, which would in turn lead to validation check
failures and decryption errors.
(5) Finally, a multipart/pem content is constructed, which
contains the new part and a corresponding application/pem
part containing the <pemhdr>. The multipart/pem content
replaces the original content.
6. Message Delivery
When a user receives a message containing a multipart/pem
content, the user agent may transform the content back into
its original form prior to privacy-enhancement. This
operation, the post-delivery algorithm, is performed by
reversing the steps performed during the pre-submission
Expires Oct 18, 1993 [Page 7]
draft MIME-PEM Interaction Apr 93
algorithm.
When the original content is reconstituted into its MIME
binary canonical form, it may use octet values outside of the
US-ASCII repertoire and may contain body parts without line
breaks. If the user agent replaces the multipart/pem content
with the original content, then it must select appropriate
Content-Transfer-Encodings for each body part and add
corresponding Content-Transfer-Encoding: headers.
Upon successful completion of the post-delivery algorithm for
each content, the type of privacy enhancement that was in
effect for that content must be communicated to the user.
Once again, the semantics of these indicators closely parallel
those of a Content- header. If a header is actually used to
communicate or store this information, it is suggested that a
new header field, "Content-Annotation," be used for this
purpose. The syntax of this suggested header field, using the
ABNF notation of [1], is:
content-annotation ::= "Content-Annotation" ":"
annotation-value
annotation-value ::= <privacy-value> ";" <date-time>
with <privacy-value> corresponding to the privacy-enhancement
that was in effect during submission, and <date-time>, defined
in [1] and [2], indicates the date and time when the privacy-
enhancement was verified by the receiving user agent.
NOTE
As with requests for privacy enhancement to the pre-
submission algorithm, the path between post-delivery and
actual display of the message must be a trusted one, lest
a message be presented that purports to have had a
<privacy-value> it did not in fact possess.
7. Examples
For example, suppose the following message was being readied
for submission:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
Expires Oct 18, 1993 [Page 8]
draft MIME-PEM Interaction Apr 93
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Privacy: mic-only
Hi Ned. See how much nicer this works!
After applying pre-submission algorithm, the message submitted
for delivery would appear as:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="next-part";
privacy=mic-only
--next-part
Content-Type: message/pem-clear
Content-Type: text/plain; charset=us-ascii
Hi Ned. See how much nicer this works!
--next-part
Content-Type: application/pem
Proc-Type: 4,MIC-ONLY
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--next-part--
After applying the post-delivery algorithm, the resulting
message would appear as:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Expires Oct 18, 1993 [Page 9]
draft MIME-PEM Interaction Apr 93
Content-Type: text/plain; charset=us-ascii
Content-Annotation: mic-only;
Thu, 12 Nov 1992 22:13:40 -0800
(integrity verified)
Hi Ned. See how much nicer this works!
The following privacy-enhanced message illustrates how an
entire message can receive enhancement.
Date: Mon, 29 Mar 93 13:57:08 -0500
From: Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Forwarded integrity Message
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="Privacy Boundary";
privacy=mic-only
--Privacy Boundary
Content-Type: message/pem-clear
Content-Type: multipart/mixed; boundary="Middle Boundary"
--Middle boundary
Content-Type: text/plain; charset=us-ascii
The enclosed message was integrity enhanced.
Greg V.
--Middle Boundary
Content-Type: multipart/pem; boundary="Forwarded Message"
privacy=mic-only
--Forwarded Message
Content-Type: message/pem-clear
Content-Type: message/RFC822
Date: Mon, 29 Mar 93 13:53:02 -0500
Expires Oct 18, 1993 [Page 10]
draft MIME-PEM Interaction Apr 93
From: Ned Freed <ned@innosoft.com>
To: Greg Vaudreuil <gvaudre@IETF.CNRI.Reston.VA.US>
Subject: Minimal PEM Message
This is a mic-clear message using 822 pem.
Greg V.
--Forwarded Message
Content-Type: application/pem
Proc-Type: 4,MIC-ONLY
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Forwarded Message--
--Middle Boundary--
--Privacy Boundary
Content-Type: application/pem
Proc-Type: 4,MIC-ONLY
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Privacy Boundary--
Expires Oct 18, 1993 [Page 11]
draft MIME-PEM Interaction Apr 93
The following privacy-enhanced message illustrates the use of
encryption and the application/encrypted content type.
Date: Mon, 29 Mar 93 14:36:40 -0500
From: Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
To: Jim Galvin <galvin@TIS.COM>
Subject: Example Encrypted Message
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="PEM Boundary";
privacy=encrypted
--PEM Boundary
Content-Type: application/encrypted
Content-Transfer-Encoding: base64
8R/EVhZy7OU=
--PEM Boundary
Content-Type: application/pem
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,4C776432D61A9829
Originator-ID-Asymmetric: ...,09
Key-Info: RSA,...
MIC-Info: RSA-MD5,RSA,...
--PEM Boundary--
8. Observations
The use of the pre-submission and post-delivery algorithms to
combine PEM and MIME capabilities exhibit several properties:
(1) It allows privacy-enhancement of an arbitrary content,
not just an entire RFC 822 message.
(2) For a multipart or message content, it allows the user to
decide whether the structure of the content should
receive what sort of privacy-enhancement.
Expires Oct 18, 1993 [Page 12]
draft MIME-PEM Interaction Apr 93
(3) It provides for a messages containing several privacy
enhanced contents, thereby removing the requirement for
PEM software to be able to generate or interpret a single
content which intermixes both unenhanced and enhanced
components.
(4) It minimizes confusion when viewing a MIC-ONLY content
without a PEM-capable user agent.
(5) It minimizes confusion when viewing a MIC-ONLY content
with a MIME-capable user agent that is not PEM-capable.
9. Acknowledgements
David H. Crocker suggested the use of a multipart structure
for MIME-PEM interaction.
10. References
[1] D.H. Crocker, Standard for the Format of ARPA Internet
Text Messages, RFC 822, August, 1982.
[2] R. Braden, Editor, Requirements for Internet Hosts --
Application and Support, RFC 1123, October 1989.
[3] N. Borenstein, N. Freed, Multipurpose Internet Mail
Extensions, RFC 1341, June 1992.
[4] J. Linn, Privacy Enhancement for Internet Electronic
Mail -- Part I: Message Encryption and Authentication
Procedures, RFC 1421, DEC, February 1993.
[5] S. Kent, Privacy Enhancement for Internet Electronic
Mail -- Part II: Certificate-Based Key Management, RFC
1422, BBN, February 1993.
[6] D. Balenson, Privacy Enhancement for Internet Electronic
Mail -- Part III: Algorithms, Modes, and Identifiers, RFC
1423, TIS, February 1993.
[7] B. Kaliski, Privacy Enhancement for Internet Electronic
Mail -- Part IV: Key Certification and Related Services,
RFC 1424, RSA Laboratories, February 1993.
Expires Oct 18, 1993 [Page 13]
draft MIME-PEM Interaction Apr 93
11. Author Addresses
Steve Crocker
Trusted Information Systems
email: crocker@tis.com
Ned Freed
Innosoft International, Inc.
250 West First Street, Suite 240
Claremont, CA 91711
USA
Tel: +1 909 624 7907
Fax: +1 909 621 5319
email: ned@innosoft.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Moutain View, CA 94043-2186
Tel: +1 415 968 1052
Fax: +1 415 968 2510
email: mrose@dbc.mtview.ca.us
Expires Oct 18, 1993 [Page 14]